1. Technical Field
The present invention relates to wireless communications, and, more particularly, to management of wireless communications between Evolution Data Optimized (EV-DO) access nodes and EV-DO access terminals.
2. Description of Related Art
Many people use mobile stations, such as cell phones and personal digital assistants (PDAs), to communicate with cellular wireless networks. These mobile stations and networks typically communicate with each other over a radio frequency (RF) air interface according to a wireless communication protocol such as Code Division Multiple Access (CDMA), perhaps in conformance with one or more industry specifications such as IS-95 and IS-2000. Wireless networks that operate according to these specifications are often referred to as “1xRTT networks” (or “1x networks” for short), which stands for “Single Carrier Radio Transmission Technology.” These networks typically provide communication services such as voice, Short Message Service (SMS) messaging, and packet-data communication.
Recently, service providers have introduced mobile stations and wireless networks that communicate using a protocol known as EV-DO, which stands for “Evolution Data Optimized.” EV-DO networks, operating in conformance with industry specification IS-856, provide high rate packet-data service (including Voice over IP (VoIP) service) to mobile stations using a combination of time-division multiplexing (TDM) on the forward link (from the network to mobile stations) and CDMA technology on the reverse link (from mobile stations to the network). Furthermore, some mobile stations, known as hybrid mobile stations or hybrid access terminals, can communicate with both 1x networks and EV-DO networks.
In the EV-DO context, a mobile station is typically referred to as an access terminal, while the network entity with which the access terminal communicates over the air interface is known as an access node. The access node typically includes a device known as a radio network controller (RNC), which is similar to a base station controller (BSC) in 1x networks. The access node also includes one or more base transceiver stations (BTSs) or “Node-Bs,” each of which include one or more antennas that radiate to define respective wireless coverage areas. Among other functions, the RNC controls one or more BTSs, and acts as a conduit between the BTSs and an entity known as a packet data serving node (PDSN), which provides access to a packet-data network. Thus, when positioned in one of these wireless coverage areas, an access terminal may communicate over the packet-data network via the access node and the PDSN.
In addition to VoIP communication, access terminals frequently engage in other types of packet-data communication, such as instant messaging (IM) and web browsing. Each instance of an access terminal engaging in a type of packet-data communication for a period of time may be deemed a “packet flow,” which would typically involve Internet Protocol (IP) packets being sent and received by the access terminal. For example, a given VoIP call may be referred to as a VoIP packet flow. Thus, as examples, an access terminal may engage in VoIP packet flows, IM packet flows, push-to-talk (PTT) packet flows, streaming-video packet flows, streaming-audio packet flows, video-telephony packet flows, and best-effort packet flows such as web-browsing packet flows and file-transfer-protocol (FTP) packet flows.
To address the fact that access terminals engage in these various types of packet flows, a particular revision of EV-DO specifications, known as EV-DO Rev. A (“EV-DO-A”), provides for what are known as profile IDs, which are identifiers associated on a one-to-one basis with types of packet flows. Thus, one profile ID may be associated with VoIP packet flows (i.e., “conversational voice”), while another may be associated with best-effort packet flows, and so on. Again, an access terminal may be able to communicate according to more than one profile ID, reflecting that it can engage in more than one type of packet flow.
Furthermore, to participate in one or more of these various types of packet flows, an access terminal may run (i.e., launch, enable, execute, etc.) particular communication applications, perhaps in response to receiving one or more user commands. As an example, to be able to participate in push-to-talk (PTT) packet flows, the access terminal may enable a PTT application. As another example, to be able to participate in IM packet flows, an access terminal may run an IM application. As yet another example, to be able to engage in web-browsing packet flows, an access terminal may launch a web browser.
To initiate connectivity, when powered on in a coverage area of an access node, an access terminal may send what is known as a Universal Access Terminal Identifier (UATI) request to the access node. The access node may respond by granting a UATI to the access terminal in a message known as a UATI response. This UATI response typically contains the granted UATI, which then serves to identify the access terminal to the access node for some period of time.
After acquiring a UATI, the access terminal will typically communicate with the access node over the air interface to set up what is referred to as a “session.” Essentially, an access terminal that has a session with an access node can engage in packet-data communication over the packet-data network to which the access node and the PDSN provide access. Conversely, an access terminal that does not have a session with an access node can not engage in packet-data communication over the packet-data network.
As part of setting up the session, the access terminal sends a connection request to the access node, requesting an air-interface connection. The access node will responsively work to establish the air-interface connection with the access terminal, which involves the access node instructing the access terminal to communicate with the access node over what is known as a traffic channel. This traffic channel takes the form of particular timeslots on the forward link, during which the access node sends data to the access terminal, and a particular CDMA channel on the reverse link, over which the access terminal sends data to the access node.
In addition to establishing the connection with the access terminal, the access node takes a number of other actions, one of which is to validate that the access terminal is authorized to engage in packet-data communication via the access node. Another such action is to set up a radio-packet (e.g., A10/A11) connection between the access node and the PDSN on behalf of the access terminal. The access node also facilitates establishment of a data link (e.g., a point-to-point protocol (PPP) connection) between the access terminal and the PDSN. The access node may also facilitate assignment (e.g., by the PDSN or by a Mobile-IP home agent) of an IP address to the access terminal. Finally, the access terminal and the access node negotiate over the traffic channel to agree on a set of profile IDs for the access terminal to use during the session; in other words, they agree as to the types of packet flows in which the access terminal is capable of engaging and in which the access terminal is permitted to engage.
Once those steps are complete, the access terminal has a session with the access node, and can therefore communicate over the packet-data network via the access node and the PDSN, according to the agreed-upon set of profile IDs. The air-interface connection is then typically torn down, freeing up those resources for other access terminals. Both the network and the access terminal maintain data pertaining to the rest of what was established, however, including the IP address, radio-packet connection, and data link. This transition from having a traffic channel to not having one is referred to as the access terminal going from active to dormant.
Thereafter, if the access terminal wants to initiate communication, it will send another connection request to the access node, which will again assign a traffic channel to the access terminal. If, on the other hand, the access node receives data addressed to the access terminal (and the access terminal does not currently have an active traffic channel), the access node would typically send a page to the access terminal over a channel known as the control channel. Perhaps in that page, or in an ensuing message, the access node will assign a traffic channel to the access terminal. The access terminal can then engage in one or more packet flows of any of the negotiated types, over the packet-data network, using the traffic channel, as well as the previously-established IP address, radio-packet connection, and data link.
As part of setting up a packet flow, either the access terminal or the access node, or both, may send the other a message known as a ReservationOnRequest (RoR), which includes at least one profile ID, indicating the type of packet flow that is being requested. Once an RoR has been sent and acknowledged, the access terminal has an “open reservation” on the traffic channel, associated with the profile ID that was included in the RoR; in other words, the open reservation is associated with the type of packet flow in which the access terminal is then able to engage. An access terminal may have multiple open reservations on the traffic channel, corresponding to the fact that the access terminal can engage in multiple packet flows at one time.
The network typically uses this profile-ID information to apply a particular quality of service (QoS) to the packet flow, which essentially means providing a particular level of packet forwarding (or “expedited forwarding”) treatment to certain packet flows. This traffic shaping is also known as “DiffServ” (“differentiated services”). Thus, a profile ID effectively represents a set of QoS characteristics to be applied to a packet flow.